Subject: Issues with RTP connection activation

From: [email-masked] (Matthew Finlayson)
Date: Mon, 18 Apr 94 16:06:10 BST

We have come across problems with the HPR spec in the area of RTP connection
activation (7.2.2). Specifically - there seems to be no provision made for
failures during connection activation.

The first issue seems to occur when a connection setup NLP (one containing the
'CS' optional RTP segment) arrives at a destination node containing no
listening RTP context (this might happen if the destination node was
suffering from resource depletion). Our assumption is that the destination
node should simply drop the request, since there is no mechanism for
rejecting a connection setup message.

If this is so, it appears to raise other issues. Presumably, the RTP
SHORT_REQ timer at the origin node will be running (since the message
contained a status request), and will time out. Next the origin node will
attempt to initiate a status exchange, which will also fail and will be
retried until the retry limit is reached. At this point, the protocol would
indicate that a path-switch should be tried. There appear to be issues with
the mechanics of this - the origin RTP context is not yet in CONNECTED state,
so it is unclear whether a path-switch is valid, or how it should be
signalled to the remote end (presumably the originating RTP must resend the
CS request, rather than just a STATUS segment).

Taking the scenario one step further, there seem to be problems in the
situation where the CS messages successfully reaches an RTP context in the
destination node, but the message containing the CIE segment fails to return
to the origin node. Since this message does not contain a status request,
is appears that there is a chance that this message will be lost and never
resent. (In the situation where both ends trigger a path switch, and the
destination node wins.)

Looking at the XTP specification (from which I believe that RTP draws many of
its concepts) I notice that (XTP revision 3.6, page 51) there the concept of
a 'FIRST' packet (their equivalent of an CS request) 'subsuming' an earlier
active context. Is this the sort of mechanism envisaged in RTP (ie. the
originating RTP retries the CS request with a different sync value) ?

XTP also seems to have the means of rejecting FIRST requests (with a DIAG
packet) - there seems to be no counterpart in RTP.

What are your ideas about these issues?

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================